Protocol translation is one technique to realize communication between two terminals under circumstances where a network to which one terminal is attached and another network to which the other terminal is attached run on different communication protocols.
For instance, concerning the Internet Protocol (IP) for use on the Internet, the Internet Protocol version 4 (IPv4) is now in common use throughout the world, but there is a concern about depletion of available addresses. To solve this problem, the Internet Protocol version 6 (IPv6) has been proposed and has reached the stage of its implementation. However, for all existing systems on the Internet, concurrent transition from IPv4 to IPv6 is practically impossible. Accordingly, methods of IP packet protocol translation for interconnecting a node on a network using IPv4 and a node on a network using IPv6 and enabling communication across these networks have been proposed. As concrete examples of these conversion methods, the following are known: “NAT-PT” described in Request For Comments (RFC) 2765 and RFC 2766 published by the Internet Engineering Task Force (IETF); “SOCKS64” described in RFC3089; “transport relay” described in RFC3142; and so forth.
In any of these techniques, IPv4/IPv6 address translation rules for mutual translation between IPv4 addresses and IPv6 addresses must have been created and held beforehand. This translation rules may be set statically in advance or may be created dynamically each time a communication path established. In the latter case, a name resolution technique in the Domain Name System (DNS) is used to trigger generation of a translation rule.
The DNS is a system to search out attributes (resource record) associated with a fully qualified domain name (FQDN), which is assigned to each device connected to a network and uniquely defined all over the world. Generally, the DNS is used to obtain an IP address from a domain name. This process of obtaining an IP address from a domain name is called name resolution. Nowadays, most applications taking advantage of the Internet obtain the IP address of a corresponding node to which to communicate with, using the DNS.
When IPv4/IPv6 translation is required, this DNS is used and a DNS message which must be transmitted to initiate communication is always monitored, and an IP address translation rule is created, triggered by a name resolution request message. Moreover, the IP address in a name resolution response message is replaced by an IP address determined, according to the created address translation rule, and the name resolution response message is sent back to the requester. To provide these functions, a DNS proxy server linked with an IPv4/IPv6 translator is employed between terminals (clients) which may send a name resolution request and a DNS server to which a query is sent.
A practical example of this operation for a scenario where communication is initiated from an IPv6 client to an IPv6 client will be discussed below.
First, the IPv6 client which is an originating terminal sends a query about the IPv6 address of the receiving terminal (client) to the DNS proxy server for name resolution. Upon having received this query, the DNS proxy server forwards this query to another DNS server and receives notification of the address of the receiving terminal (client) from the DNS server in the response to the query. Here, if the notified address is an IPv4 address, the DNS proxy server replaces the IPv4 address in the response message by a temporary IPv6 address and returns this IPv6 address to the IPv6 client. At this time, the DNS proxy server requests the IPv4/IPv6 translator to create an address translation rule that maps the IPv4 address before being replaced to the temporary IPv6 that replaces the IPv4 address. The created address translation rule is held in a table (address translation table) in the IPv4/IPv6 translator.
The originating IPv6 client transmits an IPv6 packet to the temporary IPv6 address of the receiving terminal, which was notified as the result of the name resolution. The source address of this IPv6 packet is the IPv6 address of the originating client. The IPv4/IPv6 translator receives this IPv6 packet, refers to the address translation table and searches for the IPv4 address associated with the destination IPv6 address of the IPv6 packet. Because the mapping between the IPv4 address and the temporary IPv6 address created at the time of the name resolution is held in the address translation table, the IPv4 address of the receiving terminal (client) can be obtained.
Then, the IPv4/IPv6 translator refers to the address translation table and searches for the IPv4 address corresponding to the source IPv6 address of the IPv6 packet. However, an address translation rule for the source address has not yet been created at this point of time and, therefore, the target IPv4 address cannot be obtained. The IPv4/IPv6 translator newly assigns the originating client terminal a temporary IPv4 address mapped to its IPv6 address and registers this address translation rule into the address translation table. Then, the source and destination IPv4 addresses are obtained. The IPv6 packet is translated into an IPv4 packet having the source and destination IPv4 addresses which replaced the corresponding IPv6 addresses and the IPv4 packet is transmitted to the receiving destination.
Subsequent packets to be transmitted between both clients (terminals) are translated-between IPv6 and IPv4, according to the address translation rules, as both source and destination address translation rules have been registered into the address translation table. Because the address translation rules dynamically generated for a communication are temporary, they are discarded upon the elapse of a predetermined time after the termination of the communication.
While the communication initiated from the IPv6 client to the IPv4 client has been discussed in the foregoing example, address translation rules are generated and communication is performed by way of address translation in the same procedure as described above for other situations where the IPv4 client initiates communication to the IPv6 client, where communication is performed between IPv4 clients, but requiring address translation (for example, communication across two IPv4 private networks where duplicated addresses may exist), where communication is performed, using communication protocols other than IP, and so on (for example, refer to Japanese Patent Document Cited 1).
For mapping between an IPv4 address and an IPv6 address, using the above-mentioned DNS, the IP address included in a name resolution response message must be replaced by another one. This IP address is included in a payload following an IP header, not in the IP header.
In the DNS, in reverse to obtaining an IP address by specifying the domain name of a corresponding node to which to communicate with, a process called “reverse lookup” is also be performed, in which, by specifying an IP address, the domain name of the corresponding node assigned the IP address is obtained. This reverse lookup is mainly used for e-mail, server-to-client communication, and the like.
Particularly, in a network topology where an IPv4 network and an IPv6 network are interconnected by protocol translation means, e-mail is a practically essential service. As transition to IPv6 is in progress in access networks, a further increase in demand for connecting, for example, an IPv6 client on a user terminal to an existing server on an IPv4 network is expected in future. Accordingly, in order to implement these services, it is essential to perform a reverse lookup through the DNS to look up of an IPv4 address from the IPv6 network side and to lookup of an IPv6 address from the IPv4 network side.
In the communication environment requiring IP address translation, a client terminal communicates with a corresponding client terminal, regarding a temporary IP address assigned to the corresponding client by the address translator as the IP address of the corresponding client. Accordingly, when the client terminal sends a reverse lookup query, the client would specify the temporary IP address of the corresponding client and make the query about its domain name. On the other hand, a DNS server holds a mapping between the actual IP address of a client terminal and its domain name. In order to properly obtain the domain name of the corresponding client, a query about the actual IP address of the client terminal must be sent to the DNS server. Thus, to perform a reverse lookup through the DNS in a network topology involving an IPv4 network and an IPv6 network, the temporary address of the corresponding client specified for query from the client terminal that is a reverse lookup requester must be translated into its actual address to be recognized by the DNS server.
In a packet for a reverse lookup through the DNS, specifically, an FQDN for reverse lookup corresponding to an IPv4 address or IPv6 address which serves as a query key is stored in the payload portion of the packet, following the IP header. Accordingly, the FQDN for reverse lookup in the payload portion must be translated for IP address translation. For address translation in such a packet including an IP address in the payload portion, translation in both the IP header and the payload can be performed simultaneously by a protocol translation means with support for an application level gateway (ALG), such as SOCKS64. However, because all translation process is performed by application software, high-speed protocol translation is hard to execute.
Meanwhile, protocol translation by NAT-PT involves only IP header change and the translation function is performed by dedicated hardware, and, therefore, high-speed translation can be executed. For ordinary inter-protocol communication, in most cases, translation processing is required only in the IP header and translation is not necessary in the payload. In view hereof, the NAT-PT is advantageous in terms of a total processing speed. However, if translation is necessary in the payload, an ALG must be provided separately and the packet must be transferred to the ALG for further translation after translation in the IP header is completed by an IPv4/IPv6 translator.
When, in addition to the NAT-PT, one or more ALGs for translation in the payload, such as DNS proxy servers, are used, it is a problem where address translation rules are maintained. In view of processing speed, it is considered the best that an IPv4/IPv6 translator which most frequently refers to the address translation rules maintains these rules. In such cases, the one or more ALGs query the IPv4/IPv6 translator about a substitutive address when executing address translation in the payload.
[Non-Patent Document Cited 1]
E. Nordmark, “RFC2765,” “online,” February, 2000, Internet <URL: http://www.ietf.org/rfc/rfc2765.txt>
[Non-Patent Document Cited 2]
H. Kitamura, “RFC3089,” “online,” April, 2001, Internet <URL: http://www.ietf.org/rfc/rfc3089.txt>
[Non-Patent Document Cited 3]
J. Hagino, et al., “RFC3142,” “online,” July, 2001, Internet <URL: http://www.ietf.org/rfc/rfc3142.txt>
[Japanese Patent Document Cited 1]
JP-A No. 156710/2000
If an IPv4 network and an IPv6 network which are of a large scale are interconnected, parallel use of a plurality of IPv4/IPv6 translators at one connection point is conceivable for load balancing and fail-free operation. In network topology variety, IPv4 private networks using private address allocation defined in RFC1918 are supposed to connect to an IPv6 network, where datagram is transferred from the IPv4 networks to the IPv6 network and vice versa and datagram transferred between different IPv4 networks, taking advantage of combination of IPv4 to IPv6 translation and IPv6 to IPv4 translation.
However, conventional ALGs to make translation in the payload were unable to determine which one of multiple IPv4/IPv6 translators to which to send a request.